大綱

• 現有的風格指南摘要
• 團隊開發的建議
• 最推薦的做法
• 實務又是如何進行的

現有的風格指南摘要

• idiomatic.js：Principles of Writing Consistent, Idiomatic JavaScript
• Google JavaScript Style Guide
• jQuery JavaScript Style Guide
• Airbnb JavaScript Style Guide
• GitHub 上的 Popular Conventions
• JavaScript, the winning style

重點

• 不需要再去寫另一種風格指南。
• 也許就沿用某一種風格指南，接著再去修正某些規則。

團隊開發的建議

這裡我會掌握幾個大的重點前進。

程式碼應該前後一致

1. 如果是開始一個新專案，哪就選定一種撰寫規則，並且請團隊內的人，都共同遵循著這個規則。
2. 如果是加入了現有專案的開發，哪就要遵循這個專案的規則開發。

程式碼應該容易理解

1. 通常我們花在閱讀又或者是說在看一段程式碼會比去寫一段程式碼還要得多。
2. 今天寫了一段程式法，結果一個月後來看自己寫的程式碼，還會發現看不懂，哪是一件很可怕的事。

較短不一定會更好

1. 以變數命名來看：如果我今天有一個 function 是要去呼叫產品的 API，該 function 名稱叫fetchData，我會覺得這很抽象，我會改叫fetchProductData。
2. 以檔名命名來看：如果我使用了 Bootstrap 提供的元件，該檔案名稱叫 Modal，我也會覺得這太抽象了，會配合這個功能的實作，我會改叫NotificationModal。

好的程式碼就像教科書一樣

1. 把很龐大的 function 拆成小 function，同時賦於有意義的名稱 / 說歸說，很難實行。
2. 也許可以加上註解 / 這裡就我的經驗來講，就見人見智了。
3. 附上相關的說明文件 / 這裡就我的經驗來講，就見人見智了。

重點

1. 首先請團隊內資深工程師，訂定及選擇好哪一種風格指南，並且請團隊內的大家共同遵守。
2. 從檔案到任何一個變數名稱的命名，請都賦於有意義的名稱。
3. 通常在開發的時候，都會有時程的壓力，程式寫很醜不要緊起碼功能有完成，日後可以再來重購這樣。
4. 最後，如果是寫 function 的時候，請附上 JSDoc，完整標記著 Input & Output。

最推薦的做法

大括號的使用風格

1TBS (One True Brace Style)

// One True Brace Style
function foo(x, y, y) {
	....
}

歸納

• 推薦使用 1TBS (One True Brace Style)。現今應該沒有團隊是使用 Allman style 的吧。

優先使用字面值，而非建構器

• 不要使用建構器。
• 講範例。

// 不推薦
var obj = new Object();
var arr = new Array();
var str = new String();
var num = new Number();
var bool = new Boolean();

// 推薦
var obj = {};
var arr = [];
var str = String();
var num = Number();
var bool = Boolean();

條件式運算子

// 三元運算式的不好範例
return x === 0 ? 'red' : x === 1 ? 'green' : 'blue';

// 比較推薦
if (x === 0) {
	return 'red';
} else if (x === 1) {
	return 'green';
} else {
	return 'blue';
}

// 最推薦
switch (x) {
	case 0:
		return 'red';
	case 1:
		return 'green';
	default:
		return 'blue';
}

補充 (以 React 的 Component 為例)

// 這是 React 的 Component
export const ModeIcon = ({ cell }) => {
  switch (cell) {
    case 'AIR':
      return <div className='text-info'><i className='fas fa-plane' /></div>
    case 'SEA':
      return <div className='text-info'><i className='fas fa-ship' /></div>
    case 'RAIL':
      return <div className='text-info'><i className='fas fa-train' /></div>
    case 'TRUCK':
      return <div className='text-info'><i className='fas fa-truck' /></div>
    default:
      return { cell }
  }
}

ModeIcon.propTypes = {
  cell: PropTypes.string.isRequired,
}

縮寫 if 陳述句

// 不好
foo && bar()

if (foo) {bar()}

foo || bar()

if (!foo) {bar()}

遞增運算子

// 不安全也不好閱讀
return ++foo

// 推薦
++foo
return foo

檢查 undefined

if (x === undefined) {x = 0}

ECMAScript 5：尾隨的逗號

// 好的做法
var obj = {
	first: 'Jane',
	last: 'Doe',
}

補充

// I18n 翻譯檔
const MilestoneEdiStatusQuery = {
  required: 'Required',
  query: {
    clientIdList: 'Customer Code',
    ediMappingStatusList: 'EDI Status',
    masterNumberList: 'MAWB / MBL',
    hawbNumberList: 'HAWB / HBL',
    deliveryNumberList: 'DN / SID',
    hawbOriginPortList: 'Orig',
    hawbDestinationPortList: 'Dest',
    ediRequestedStartOn: 'EDI Req. Date',
    ediRequestedEndOn: ' ',
    ediSentStartOn: 'EDI Sent Date',
    ediSentEndOn: ' ',
    shipmentModeList: 'Mode',
    milestoneStatusList: 'Milestone Status',
  },
}

export default MilestoneEdiStatusQuery

語法

跟空白有關

var result = foo(1, 2) // 左括弧之後跟右括弧之前不會有空白

var arr = [1, 2, 3] // 逗號後面會空一格

const foo = function (x) {...} // 匿名 function，會在關鍵字 function 後面空格 

縮排採用四個空格

見人見智，像是我就非常不喜歡。

把條件式運算子放在括弧中

return x === 0 ? 'red' : 'blue'; // 不建議

return (x === 0 ? 'red' : 'blue'); // 好的做法

變數

每行包含一個變數宣告

// 不建議
var foo = 3,
		bar = 2,
		baz;

// 好的做法
var foo = 3;
var	bar = 2;
var	baz;

變數宣告區域性

// 不建議
if (v) {
	var x = v;
} else {
	var x = 10;
}

// 好的做法
var x;
if (v) {
	x = v;
} else {
	x = 10;
}

強制轉型

Coercion (強制轉型) 可分為兩種，分別是「明確的」強制轉型 (explicit coercion) 和「隱含的」強制轉型 (implicit coercion)，只要是程式碼中刻意寫出來的型別轉換的動作，就是明確的強制轉型；反之，在程式碼中沒有明確指出要轉換型別卻轉型的，就是隱含的強制轉型。

• 一律使用「明確的」強制轉型的語法。

'3' * '4' // 12, number

Number('3' * '4') // 12

實務又是如何進行的

時空背景：不管是寫 JavaScript 的原生、Vue、React or Angular 也好。

編輯器：以 Visual Stadio Code (VSCode) 為舉例。

套件：會使用 ESLint、Prettier 來協助開發。

目的：確保整個團隊開發的風格一致。

ESLint

ESLint 是一個 Javascript Linter，他能確保你的程式碼品質在一定的水準之上，是我自己寫 JS 時一定會使用的工具之一，在團隊內也很建議使用他以確保被提交上去的程式碼品質。

Linter 可以幹嘛

Linter 會幫你做靜態語法分析，在你執行之前抓出可能的錯誤，大部分的 Linter 會有以下幾個功能：

1. 幫你找出語法錯誤**：**沒宣告變數就拿來用、少了括號等等常見的語法錯誤。
2. 確保你遵循最佳實踐**：**不使用全域變數、建議使用 === 而非 ==、不使用 eval …。
3. 提醒你刪掉多餘的程式碼**：**有些變數宣告了卻沒有使用、import 了沒有使用的模組、空的 class constructor …。
4. 統一基本的 coding style：要不要加分號、使用單引號或雙引號、縮排使用 space 或 tab 等等。

目前比較熱門的 style guide 有 Google、Airbnb 跟 Standard 三個，使用 style guide 的好處就是不用自己設定規則，但彈性稍低。